fix(widget): show context-limit message on HTTP 429 token budget exceeded and disable composer - #62

… user

Review feedback on extra-org#59, all three points:

1. The widget remembered the active conversation under a key built from the
   endpoint alone, so a second user on the same browser (shared machine, or a
   host app signing someone else in via `<agent-chat user="...">`) resumed the
   previous user's chat. The key is now `agent-chat:<endpoint>:<userId>`.

2. `user_id` was sent when a conversation was created but not on send/stream,
   so the run executed with `RunContext.user_id = None` — exactly the field
   hooks and tools authorize on. The service now loads the session and takes
   the identity from it: a caller that omits user_id runs as the session's
   owner, and one that supplies a *different* user_id is refused with
   ConversationAccessDenied (403) instead of being silently rebound. The
   browser no longer decides who it is on a turn.

3. `GET /conversations?user_id=` stays a scoping parameter, not an
   authorization boundary — now stated in the route's docstring, with the
   place to put real auth.

`_require` returns the session it already had to fetch, so the ownership check
costs no extra query.

Tests: a turn with no client user_id runs as the owner; a mismatched user_id
raises and persists nothing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Show a bouncing-dots indicator while the assistant has no answer text
yet, and keep it visible when the user leaves a streaming thread and
returns.

Messages now live in a per-conversation map keyed by the id captured at
submit time, so switching threads only swaps the view — the in-flight
stream keeps writing to its own bucket. `typing` means "stream in
flight" (set at submit, cleared at completion); reduceStreamEvent is
reduced to content accumulation only, fixing dots that could otherwise
linger on an empty final answer.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Review feedback on extra-org#60: stream(), send(), loadHistory() and loadUsage()
each re-read the active conversation id from localStorage when they ran.
A turn that started in thread A but finished after the user switched to B
could retry, or refresh usage, against B. Storage now only remembers which
thread was selected last; it never decides where an in-flight request goes.

- Conversation methods take the id: send(id, text), stream(id, text),
  loadHistory(id), loadUsage(id). The app already captures the id at submit
  time for its per-conversation message map, so it passes that same id.
- Usage moves into a per-conversation map alongside messages, so a late
  response cannot paint another thread's number.
- Stale-conversation recovery (404 -> create a new one) now reports the
  replacement through `onReplaced`, and the app re-keys that thread's
  messages onto the id the turn actually ran under instead of leaving them
  stranded under the dead one.

Test: a turn whose stream fails after the user switched threads retries on
its own conversation, and the usage refresh follows it — both landed on the
other thread before this change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>